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Scratch games in which a player is moved with directional keys and slowed 
with friction often use this method: 
vel+ = acc 
velx = friction 


position+ = vel 


This method is mostly fine, though imperfect. It has two flaws, one major and 
one minor: 


e The method does not account for the frame rate 


¢ The method treats changes in velocity and position as discrete steps rather 
than a continuous change. 


The first flaw is something that is often not noticed in Scratch, as the game 
usually caps the frame rate at 30FPS. In other games where the frame rate is 
uncapped or not constant, there may be noticeable changes in the speed of 
the player as time passes. Running a Scratch project in Turbowarp without a 
capped frame rate will result in players moving faster than intended. 

To solve these problems, the variables will first be shortened for convenience: 


acca 

vel > v 
friction > f 
position > d 


deltat — At 


To account for the passage of time, these changes are made: 


v+=axAt 
way 
d+=v+At 


< 


Figure 1: Graph of distance over time with naive method 


Now, the velocity and distance scale in relation to the last recorded frame time. 
Friction also scales with time, but slightly differently. Consider the scenario 
where n frames of the game are run. The friction will be applied n times, 
which, independently to all other functions is the same as multiplying v by 
f". In this case, f will be raised to the power of n, but only when n seconds 
have passed in the rendering of a frame, rather than n frames. This way, the 
correct amount of friction will be applied, whether a frame lasts for 0.1 seconds, 
5 seconds or any other value. 

Because of the changes, the constants such as a and f have to be adjusted to 
work based on time and not frames, but this is usually a simple division by the 
average frame rate. 

So, what is the problem with this method? 

It’s mostly fine, but it’s not perfect. Depending on the frame rate, a player 
may move slightly faster or slightly slower, even though we have supposedly 
already accounted for that. 

Let’s consider a scenario where a player is only accelerating, with no friction. 
Let a, At = 1 for simplicity. Let’s visualise the simulated velocity and distance 
over time with a graph: 

As depicted in Figure 1, each second is a column of time. When a second 
passes, the column increases by 1 unit of velocity, then the distance increases 
by the area of the column. Since the width of each column is 1, as At = 1, the 
area at each second is equal to the velocity. 

This is an imperfect calculation of the distance over time, and if the staircase 
structure did not make it clear enough, Figure 2 is an example of the same 
method with half the frame rate: Instead of operating every 1 second, it operates 


Figure 2: Naive method with At = 2 


every 2 seconds. To adjust for this, it increases the velocity by 2 instead of 1, 
and each columns width is doubled. However, despite the adjustments, the 
total shape has a larger area compared to the first. This is because the method 
applies velocity as a discrete chunk instead of considering its change between 
frames. In the ideal situation, the distance travelled would be the same for 
scenarios with an equal total time, no matter the frame rate. For this to happen, 
the graph needs to also look exactly the same in those situations. Figure 3 
shows the ideal graph to calculate distance. It keeps in mind that the velocity 
changes continuously through time, even if the game only updates at discrete 
points. To calculate this area as a function of time, the best way is to get the 
integral of v over t: 


v=at 


a= f var= f aat=$2 


This only works if the velocity has continuously been increasing since 0 and 
does not consider distance traveled in one specific frame. To do this, let’s 
consider a single frame of time: The limits of the the scenario in Figure 4 are 
more realistic, in which we only know the frame time, our current velocity and 
the acceleration. To calculate the distance i.e. the area of the shape we can use 
the equation for the area of a trapezoid: 
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Figure 3: Ideal distance calculation 
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Figure 4: One unit of time with improved method 


Figure 5: Distance under effect of friction, with both naive and improved 
method 


v+(v+aAt) 
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The first part of the equation vAt is actually the same as the original equation 
d+ =v * At, but now there’s an extra part that considers the change in velocity 
over time. Because this formula calculates the movement based on the velocity 
before it gets updated, the movement actually now needs to be updated before 
the velocity. 

In the next scenario, let’s consider the effect of friction over time. Here’s a 
graph of how a player would move under the effect of friction, starting with 
a high velocity: Figure 5 depicts both the estimated distance with the naive 
method and the intended distance with the red curve. Because the velocity is 
decelerating instead of accelerating, the naive method results in a lower total 
distance than it should be instead of higher. Just like with acceleration, to solve 
this we just need a formula that calculates the area under the curve. However, 
the trapezoid formula will not be sufficient in this case: Although Figure 6 
looks like the inverse of Figure 4, keep in mind that the descent is a curve and 
not a straight line. 


ant 


Figure 6: One unit of time under friction 


To calculate the velocity under friction after any amount of time, this formula 
is used: 


Vat = V9* f™ 


To calculate the area under the curve, we have to get the integral: 
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One neat part of this equation is that it apparently doesn’t require the amount 
of time passed, it just needs the velocity before and after the frame. 

Now that both formulas have been found, the real problem begins: How do 
we apply both at the same time? They both directly influence each other and 
there’s no clear way to combine them. 


Let’s go back to the situation where we use the naive formulas: 


vt =ax*At 
0+ = f At 
We'll combine this into one formula, but we'll apply the friction before the 


acceleration to simplify it. As At decreases and more velocity updates are 
performed, whichever one was applied first will be insignificant. 


Vat = vof*! + aAt 


It is currently a recursive formula. The value of At can be decreased and more 
iterations can be performed for a more accurate result but it will never be 
perfect. 

There are likely several ways to proceed from here but this is the path I took. 
I reapplied the formula to itself several times to see if I could find a pattern: 


oat = (var) fa! + aAt 
= (vo f*! + aAt) fA! + aAt 
= up f+ aAtf*! + aAt 
v3at = (vo f 7! + aAt fe! + aAt)f™ + aAt 
= up f*! + aAt f2™! + aAt fo +aAt 
There seems to be a clear pattern here. Every new iteration increases the value 
of n by 1 in v9 f"', and it adds a new term AE FO AL, The first part is simple 


so it can be ignored, and we'll focus on the second part. 
Looking closely, it takes the form 


BAPE GAL PO toate baat pote oo eankE et 


Where n is the number of iterations of the recursive function. As Af approaches 
0, the number of iterations will increase to make up for the shorter time, so 
we will ideally consider the result of the infinite sequence. Our sequence 
progression matches the geometric series: 


atar+ar-+ar +t... 


and because f < 1 and therefore f At < 1, it can be calculated with 77.10 
become 
at 
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And, just for fun, we can see what this becomes as At approaches 0: 
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While this looks like a nice clean formula, there is one problem: The acceleration 
and friction are constants, so this formula gives the exact same value no matter 
what. So... what does it even measure? As we are repeating the sequence 
infinitely, we are calculating the value the velocity converges to after an infinite 
amount of time. That also explains why there is no function of time in this 
equation, because it just calculates to infinity. Ironically, the problem isn’t that 
we're repeating all the way to infinity, it’s that we’re using a larger infinity than 
we're supposed to. How is using a different infinity supposed to give a different 
result? I... Don’t know exactly. Nevertheless, I can explain how to make things 
right. 

The problem is that we considered the formula for an infinite sequence 
when we're supposed to actually stop the sequence at a certain point (but at the 
same time, we’re not. You'll see soon). Let T be the total time frame we need 
to calculate the velocity in. If we use the naive method and only perform one 
iteration of the recursive function, then At = T and we get this familiar result: 


vr = vof' + adt 


Let’s say now that we halve At so At = 4 and apply the function twice for more 
precision. Now we get: 


vr = vo f-™ + aAt fo + aAt 
And three times with At = f: 
vr = vo fo! + aAtfr™ + aAtf™ +aAt 


Notice that the number of "a" terms is equal to whatever we’re dividing T by, 
ie. it equals £. Additionally, the largest value for n in the term aAtf"! is 
always 1 less than 4. Using this information, we know when the series ends, 
and we can use that to re-calculate the infinite series. We do this by using the 
geometric series formula from earlier, and including a second geometric series 


to subtract the ones we don’t want, like this: 


a+ar+ar tar? tar?+... 
-ar? _ ar* = hoes 


=a tar +ar? 
In this case, we're subtracting the terms aAt f"“' where n > = like this: 
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It might seem like it shouldn't work so simply, but... It does. 
At this point, we decrease the value of At to 0, which automatically increases 


the number of items in the series to compensate for the extra time needed to 
reach T. 
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Keep in mind that this isn’t the final velocity equation yet, we still need to add 
back in the original term we kept out: 


a(f? — 1) 
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Neat, we now have the velocity for any acceleration and friction after any given 
amount of time. Now, we just need to get the integral to calculate the total 


UT = vof? + 


distance travelled in that time frame: 
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While it doesn’t look very nice, it gives the exact distance to be travelled at every 
frame, no matter the frame rate. The formula is based off the velocity before it 


is updated, so the distance should be updated first. 
This is the end of the document. Thanks for reading. 
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